3GPP is currently standardizing the Long Term Evolution (LTE), which is the continuation of 3G networks. In LTE the ciphering and integrity protection of the user plane and the radio resource control data is performed by the base station, in this context usually referred to as the evolved Node B (eNB). When the communication link of a terminal, i.e., a User Equipment (UE), is handed over from one eNB to another eNB, the source eNB informs the target eNB about which algorithms that are supported by the UE and which algorithms that are allowed for use by the network. Out of the algorithms allowed by the network and supported by the UE and the target eNB, the target eNB then selects the algorithm that is considered to be the best, according to pre-defined selection criteria.
In such a situation, a compromised source eNB may modify the lists, indicating which algorithms the UE supports, which the network allows, and/or the priority order of the algorithms that the network supports. Since the target eNB has no possibility to verify the authenticity of these lists, it cannot detect if a malicious source eNB is tricking it into selecting a weak, and possibly even broken, algorithm. Such an attack set-up is typically referred to as a bidding-down attack.
The security working group in 3GPP has agreed to provide a solution for detection of this kind of bidding-down attack.
For the understanding of how present handover signaling can be organized such a procedure, according to the prior art, will now be described with reference to the signaling diagram of FIG. 1. The described handover signaling comply with the Technical Specification TS 36.300, “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2”, May 2008,
In a first step 1:1, a source eNB 101 configures UE measurement procedures according to the area restricted information. As indicated with steps 1:2 to 1:5, a UE 100 prepares for, and sends, a measurement report to the eNB 101 which it is currently attached to, i.e. the serving eNB which is called the source eNB in case of a handover situation, wherein UE 100 measures the strength of surrounding eNBs and reports the result. The serving eNB 101 decides to hand the UE 100 over to a selected target eNB 102, as indicated with a next step 1:6. Source eNB 101 then requests a handover from the target eNB, passing necessary information to a target eNB 102, as indicated with a next step 1:7. At this stage, the target eNB 102 may perform an admission control procedure, as indicated with another step 1:8, after which target eNB 102 accepts the request, as indicated with a step 1:9, and in response the source eNB 101 sends a handover command to the UE, which attaches to the target eNB and sends a handover confirm message to it, as indicated with another step 1:11. In subsequent steps 1:12-1:18 handover preparations, comprising e.g. synchronization, are executed between UE 100 and target eNB 102. When the target eNB 102 receives the handover confirm message sent in a step 1:19, it informs the Mobility Management Entity (MME) 104 in the core network about the new location of the UE 100, as indicated with a next step 1:20. In subsequent steps 1:21-1:28, the MME ensures that all data sent to, and received from, the UE 100 is now performed via the target eNB 102, as indicated in a final step 1:29.
According to the procedure described above, there is, however, no way for the MME 103 to verify that the information it received in the path switch request in step 1:20 is correct and trustworthy. There are currently two solutions under discussion in the security working group in 3GPP (SA WG3) for handling the problem mentioned above. One is provided in S3-080169 (P-CR) “AS algorithms selection mismatch indication” Nokia, Nokia Siemens Networks, 25-29 Feb. 2008. In short the solution described in this document suggests that, prior to executing a handover procedure, a UE is reporting its security capabilities to a Mobility Management Entity (MME), which in turn sends an allowed set of algorithms to the UE. The MME further sends a priority ordered list of algorithms, only containing algorithms supported by the UE, to the serving eNB, which selects one of these algorithms for use. If, during a handover procedure, the UE notices that the algorithm selected for use in the target cell is not included in the set of allowed algorithms, it reports this to the MME, the report including the cell identity (cell ID) of the first cell where the mismatch was detected. However, this method suffers from the problem that it is not possible for the target eNB or the UE to detect if the source eNB has modified the order of the algorithms in the networks list of allowed algorithms. Furthermore, the required reporting mechanism will be complex, since a new Non-Access Stratum (NAS) procedure, enabling the UE to report the described event to the MME, is required. Using this mechanism will also result in an increased load on the air interface between the UE and the target eNB.
Another solution to the same problem is proposed in S3-080054 “AS algorithm policy handling”. Ericsson, 25-29 Feb. 2008, and consists basically of the following steps:    1. UE sends its UE security capabilities (UE SCAP), i.e. its, supported algorithms, to the MME.    2. The MME selects a list of algorithms, here referred to as the MME_prio_list, in priority order.    3. The MME sends the MME_prio_list and the UE SCAP to the serving eNB.    4. The MME sends the MME_prio_list and the UE SCAP integrity protected to the UE.    5. The target eNB is configured via Operation and Maintenance (O&M) with a listed set of allowed algorithms, referred to as a O&M_allowed_set.    6. The target eNB selects an algorithm that can be identified in all three of the UE SCAP, MME_prio_list, and O&M_allowed_set.    7. The UE reports its MME_prio_list and the UE SCAP to the target eNB.    8. If the target eNB determines that the MME_prio_list and UE SCAP received from the UE are not the same as the ones received from the source eNB it can deduce that a bidding-down attack has occurred and can take appropriate action/s.
However, not only does this solution require a separate list of algorithms, configured in each eNB, since the UE has to provide information to the target eNB in a handover confirm command, it also increases the bandwidth usage on the established air link.